浅谈重构中踩过的坑
最近重构了公司一个将近10年的核心功能模块，踩了不少坑。在做这个重构的时候好几次都觉得做不下去，好几次压力都非常大，心想着我该不会做着做着就退出编程届了吧。
不过还好，自己还是坚持下来了，回想写这个项目的时候自己曾三次推翻重来，那种心路历程真的只有经历了才知道，真是煎熬。后来回想起这一路踩过的坑，其实更多的是经验问题，而不是技术方面的问题。
关于心态
回顾做这个项目，我觉得心态问题是最重要的，技术问题倒是其次。为什么这么说呢？因为对于10余年的老功能模块来说，其中最复杂的其实是业务逻辑，而并非技术实现。所以对于老系统的重构，你首先需要将这十余年来积淀在该模块的业务逻辑梳理清楚，这本身就给了重构者一个无形的压力。再加上又是核心业务模块，少一点业务逻辑就会导致线上收入的减少，最后就是程序员祭天的悲惨命运。这一系列的背景，使得重构之时心理压力真的很大。
现在回头来看，对于重构项目，最好的方式还是先仔仔细细梳理清楚所有的业务逻辑，之后将其用思维导图画出来，这样你会对这十几年来的业务逻辑一清二楚。清楚了业务逻辑，对于你后面进行系统重新设计以及编码都是大有裨益的，甚至是起决定性作用的一环。
说到心态这个话题，无论是做什么项目，即使是重构，也会涉及到排期问题。有时候很可能你自己还没完全了解业务逻辑之时，上级就要你给出一个排期，这时候其实作为重构者是很为难的。对于这种情况，其实我建议还是与上级做好充分的沟通，如果能延长给排期的时间是最好的。如果不能，那应该主动上报每天的进度，让上级知道你的进展。其实要你给出排期，不就是为了掌控进度吗。
当你给出排期后，很可能会出现了许多当时预估排期时没有出现的情况，这时候一般我们有两种选择：一种是急急忙忙草草处理了事，另一种则是稳定心态思考最好的解决方式。其实当你发觉另一种做法是更好的处理方式，但这种方式在目前排期下无法完成，这时候作为整体功能的开发重构人，你应该有自己的判断。即使是因为做了这件事情而延期，但只要你做的这件事情是对的，有利于系统拓展性和稳定性的，那还是应该坚持自己的选择。我想，如果你因为正确的坚持而延期，我想公司并不会因此而责怪，只要你给出了自己的理由。最怕的是惊慌失措地写完一个东西，而这东西又漏洞百出。
所以有时候觉得开发或重构一个系统真的是得抱着必死的决心，这样才能有自己的坚持，而不会在上级的排期压力之下做出错误的选择。特别对于重构类的项目，如果没有一个从容的心态，那系统是肯定做不好的。
关于技巧
我觉得重构中的经验技巧远重要于技术实力，因为一个经验可以让你减少很多不必要的麻烦。在说出我的心得之前，我想问一个问题：
在你重构的时候遇到一个问题，这个问题解决了会更好，但不解决也不会影响到此次项目的结果。请问，此时你是解决这个问题，还是不解决好？
有些人会分析：这要看情况，如果我有时间我会去解决，如果没有时间，那我就会跳过它。一般会给出这种答案的人，都是理论上的巨人，行动上的矮子，基本可以断定没有经历过实战。因为其分析很符合马克思主义的辩证主义思想啊，这也确实没错。但这样的解决方式对于实际情况是不够有用的。
对于这种情况，我建议是不做。准确地说：对于任何不影响你达成重构目标的事情，能不做就不做。因为你永远不知道这个坑到底有多深！在你并不知道坑有多深，而此时又有排期（追兵）在后面，这时候最聪明的做法就是不做。等你把必须做的做完了，你再回头来看看这个问题，如果你可以解决，那就尝试着解决。但如果此时你发现坑真的很深，你可以果断返回，这时你其实已经做完了事情，并不会有排期的压力了。这样的做法给自己留足了后路，自己可进可退，可攻可守。但如果你一开始就选择踩这个坑，那么可能你会让自己陷入泥潭。
所以建议大家在不清楚的情况下不做，不是叫大家做事懒惰。而是让大家明白自己的目的是什么，在资源（时间）有限的情况下把事情做成。
关于技术
技术是放最后的，因为我确实觉得技术在重构中并不是特别重要。至少在我这次重构中，我基本上60%的工作都是因为我的心态或技巧不足导致的重复劳动。我项目中重构涉及到的技术，我只用了不到10%的时间就完成了。回头想一想，真是觉得好凄凉。
重构中的技术其实更多的是使用设计模式将复杂的业务逻辑用简洁的代码呈现出来。简单点来说，就是用设计模式承载复杂的业务逻辑，尽可能使写出的代码简洁。
怎么样才是一个好的系统重构呢？其实有一句话说得特别好：对拓展开放，对修改封闭。意思就是说别人只能拓展你的代码，而不能修改你的代码。很多老系统为什么会越来越复杂？逻辑越来越多？原因就是他写的代码允许别人进行修改。这么说可能会很抽象，我们举个例子说吧。
if(type == apple){
//deal with apple
} else if (type == banana){
//deal with banana
} else if (type == ......){
//......
}
上面这段代码模拟的是对于水果剥皮的处理程序。如果是苹果，那么是一种拨皮方法；如果是香蕉，则是另一种剥皮方法。如果以后还需要处理其他水果，那么就会在后面加上很多 if else 语句，最终会让整个方法变得又臭又长。如果恰好这个水果中的不同品种有不同的剥皮方法，那么这里面又会有很多层嵌套。
可以看得出来，上面这样的代码并没有满足「对拓展开放，对修改封闭」的原则。每次需要新增一种水果，都可以直接在原来的代码上进行修改。久而久之，整个代码块就会变得又臭又长。
如果我们对剥水果皮这件事情做一个抽象，剥苹果皮是一个具体的实现，剥香蕉皮是一个具体的实现，那么写出的代码会是这样的：
public interface PeelOff {
void peelOff();
}
public class ApplePeelOff implement PeelOff{
void peelOff(){
//deal with apple
}
}
public class BananaPeelOff implement PeelOff{
void peelOff(){
//deal with banan
}
}
public class PeelOffFactory{
private Map<String, PeelOff> map = new HashMap();
private init(){
//init all the Class that implements PeelOff interface
}
}
.....
public static void main(){
String type = "apple";
PeelOff peelOff = PeelOffFactory.getPeelOff(type); //get ApplePeelOff Class Instance.
peelOff.pealOff();
}
上面这种实现方式使得别人无法修改我们的代码，为什么？
因为当需要对西瓜剥皮的时候，他会发现他只能新增一个类实现 PeelOff 接口，而无法再原来的代码上修改。这样就实现了「对拓展开放，对修改封闭」的原则。
其实上面这种设计模式是最基本的设计模式：抽象设计模式。对于各种复杂的业务情形，还有其他许多设计模式，例如：代理模式、装饰模式等等。但各种模式归根到底还是考察你对业务的理解能力以及抽象能力，如果你对业务足够理解，你即使不知道某个设计模式，你也会写着写着写出这样一个设计模式。
总结
此时重构的经历让我觉得十分痛苦，但熬过来了就觉得没什么了。忽然感叹道重构还是很有技巧性的，对于技术要求反而没有那么高。重构更多考验的是对业务的深入理解，对抽象思维的进一步运用。如果业务理解深入，有抽象的思维，那设计模式还可以一点点学出来。而如果反过来，则没有办法做下去。
重构何其苦，且做且前行。
来源：陈树义
http://www.cnblogs.com/chanshuyi/p/7832360.html